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INTRODUCTION 

Ongoing  military  operations  throughout  the  world  have  demonstrated  an  increased  reliance  on  the 
cooperation  and  collaboration  of  many  nations  and  multiple  services  that  employ  disparate  systems  and 
varying  procedures.  Although  combined  operations  of  the  past  seem  similar  on  the  surface,  the  coalition 
operations  of  today  typically  involve  a  greater  number  of  nations  with  more  complex  systems.  These 
complex  systems,  and  their  associated  training  systems,  were  typically  acquired  in  isolation  with  little  to 
no  consideration  given  to  interoperability.  Only  recently  have  some  nations  begun  to  expend  resources  on 
addressing  the  grander  issue  of  incompatibility  within  the  battlespace. 

Consider  the  following  anecdote  as  a  means  of  portraying  this  situation.  Within  a  larger,  long  term 
campaign,  a  two-ship  close  air  support  (CAS)  package  form  Nation  A  has  been  assigned  a  short  notice 
high  priority  target  to  assist  friendly  ground  forces  in  securing  a  strategic  objective.  The  target  area  is 
likely  well  protected,  but  it  is  in  rugged  terrain  and  the  level  of  integrated  air  defence  is  currently 
unknown.  Nevertheless,  the  CAS  package  is  launched.  Target  ingress  is  successful  and  weapons  are 
launched  as  planned;  however,  upon  initial  egress,  enemy  air  defences  engage  the  CAS  package,  and  the 
situation  is  compounded  by  local  area  unfamiliarity.  Ultimately,  one  of  the  CAS  aircraft  is  downed  leaving 
the  pilot  behind  enemy  lines.  Airborne  early  warning  and  command  and  control  assets  from  Nation  B  are 
notified,  and  a  combat  search  and  rescue  (CSAR)  effort  from  Nation  C,  in  concert  with  already  embedded 
Special  Forces  from  Nation  D,  is  initiated  immediately.  As  with  the  CAS  package,  the  CSAR  effort  is 
unfamiliar  with  the  target  area  and  must  rely  on  quick  planning  using  traditional  paper  products 
(i.e.  maps).  Although  the  rescue  effort  eventually  succeeds  (12  hours  later),  the  component  forces 
encounter  difficulties  exchanging  data  and  procedural  information,  which  nearly  compromises  the  Special 
Forces  element,  and  the  entire  mission. 

Had  the  various  elements  of  this  operation  been  able  to  train  and  mission  rehearse  in  a  networked  and 
distributed  synthetic  environment  (SE),  participating  nations  may  have  been  able  to  identify  and  correct 
some  of  the  technical  and  non-technical  issues,  resulting  in  a  more  effective  and  efficient  outcome.  Such 
an  effort  is  by  no  means  trivial  -  the  wide  range  in  roles  and  systems  necessitate  an  equally  wide  range  in 
simulation  systems  (virtual  simulators,  visualisation  and  analysis  software,  environmental  data, 
networking  elements);  however,  the  task  is  not  insurmountable,  and  the  technology  exists  today  to  make 
networked,  SE-based  training  and  mission  rehearsal  a  reality  for  coalition  forces.  Concerned  nations  and 
agencies  must  first  articulate  the  need  in  the  form  of  characteristic  solutions,  and  recognise  the  long-term 
benefits  that  initial  investments  in  SE  technology  and  processes  have  to  offer.  Of  course,  technology  does 
not  hold  all  of  the  answers;  technical  solutions  must  be  complemented  by  efforts  in  the  organisational  and 
military  cultural  domains  as  well. 

The  aim  of  this  paper  is  to  examine  some  of  the  fundamental  concepts  and  issues  surrounding 
interoperability  within  the  modelling  and  simulation  (M&S)  and  SE  realm.  By  taking  a  look  at 
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interoperability  basics,  the  concept  of  reuse  and  some  of  the  associated  challenges,  we  hope  to  shed  some 
light  on  the  feasibility  and  issues  concerning  the  collective  use  of  M&S  /  SE  tools  to  enhance  defence 
processes. 


INTEROPERABILITY  BASICS 

The  idea  of  networking  systems  together,  whether  generically  or  for  use  specifically  in  simulation  is  not 
new.  Networking  information  systems,  particularly  via  the  Internet,  has  lead  to  a  vast  increase  in  the 
availability  of  information.  Given  proper  oversight,  this  high  degree  of  information  sharing  has  the 
potential  to  increase  the  effectiveness  and  efficiency  of  virtually  any  domain1.  The  M&S  realm  recognised 
the  benefits  of  networking,  and  the  current  day  practice  of  connecting  military  simulations  over  a  wide 
area  network  (WAN)  began  with  the  SimNet  project  under  DARPA  in  the  early  1980s[l].  Over  the  past  two 
decades,  the  supporting  technology  and  processes  have  taken  networked  distributed  simulation  to  a  new 
level  wherein  complex  models  and  simulations  federate  together  to  address  a  wide  variety  of  issues  within 
the  defence  arena. 

Notwithstanding  the  significant  advances  in  technology,  the  creation  of  a  distributed  network  of  disparate 
simulations  is  certainly  not  a  trivial  task;  the  wide  variety  of  simulations  and  their  associated  applications 
have  lead  to  different  architectures  and  methods  of  interoperating.  Figure  1  identifies  some  of  the  various 
classes  of  simulations,  as  well  as  some  of  the  systems  common  to  the  United  Kingdom  (UK)  Ministry  of 
Defence  (MoD).  All  of  the  simulations  in  Figure  1  can  be  networked  but  not  necessarily  to  each  other. 
The  reason  for  this  limitation  is  that  each  of  the  simulation  examples  shown  uses  a  different  architecture 
for  networking  among  multiple  instantiations  of  themselves.  On  a  larger  scale,  in  order  to  even  begin 
thinking  about  achieving  interoperability  among  multiple,  disparate  systems,  one  must  explore  some  of  the 
fundamental  differences  in  networking  architectures. 


Wargames 


Platform  Simulators 


Command  Trainers 


Commercial  Games 


Figure  1:  Various  Networkable  Simulations. 
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Robert  Metcalfs  Law  states  that  the  value  or  power  of  a  network  increases  as  the  square  of  the  number  of  its  nodes. 
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The  early  days  of  networked  simulations  employed  what  we  will  call  the  classical  simulation  architectures 
-  architectures  that  provided  limited  networking  functionality.  Figure  2  portrays  a  schematic  of  the  classic 
Terminal  Server  architecture,  wherein  all  of  the  data  resided  and  all  of  the  battle  processing  occurred  on  a 
central  server.  The  individual  player  terminals  were  simply  graphical  interfaces  through  which  the  users 
would  respond  to  only  graphics  commands  that  were  literally  sent  from  the  central  server  to  the  individual 
player  stations.  The  Janus  wargame,  still  in  use  by  the  British  and  Canadian  armies,  functions  according  to 
this  architecture. 


Figure  2:  Terminal  Server  Architecture. 


A  comparable  architecture  from  the  perspective  of  the  user  is  shown  in  Figure  3.  Despite  the  apparent 
similarity,  the  Client  Server  architecture  is  sufficiently  different  once  one  begins  to  look  a  little  deeper. 
In  this  architecture,  all  battle  assessments  are  still  executed  on  the  central  server.  The  difference  is  that  the 
server  then  sends  battle  update  information  (vice  simple  graphics  commands)  over  the  network  and  the 
individual  client  stations  run  some  form  of  local  intelligent  processes.  Some  data  is  retained  at  the  client 
station,  which  is  displayed  on  a  locally  stored  map.  The  extent  of  local  processing  may  vary  among 
different  client  server  systems,  giving  rise  to  the  terms  Fat  and  Thin  clients.  The  ABACUS  command  and 
staff  training  (CAST)  wargame  functions  according  to  this  architecture.  Although  these  two  classical 
architectures  facilitated  networking,  it  was  done  within  a  single,  closed  system  using  proprietary 
constructs  and  protocols.  As  such,  an  attempt  to  interoperate  two  systems  such  as  Janus  and  ABACUS 
would  be  non-trivial  in  the  least,  and  may  not  even  make  sense  from  a  conceptual  and  functional 
perspective. 


Interoperability  can  carry  different  meanings  within  different  domains.  The  North  Atlantic  Treaty 
organisation  (NATO)  defines  interoperability  as: 
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“The  ability  of  Alliance  forces  and,  when  appropriate,  forces  of  Partner  and  other  nations  to 
train,  exercise  and  operate  effectively  together  in  the  execution  of  assigned  missions  and 
tasks  ”/li] 

More  simply,  the  Longman  Dictionary  of  the  English  Language  (1984)  defines  inter  as  “among  ...  carried 
on  between”  and  operate  as  “to  carry  on  military  . . .  action  or  mission”.  Essentially  interoperability  within 
a  military  context  means  for  all  participating  elements  to  have  the  ability  to  function  in  a  combined  and 
consistent  manner  to  achieve  a  common  objective.  Aside  from  any  textbook  or  academic  definition  of 
interoperability,  the  fundamental  concept  of  enabling  many  agencies  and  organisations  to  cooperate  for 
increased  effectiveness  and  efficiency  should  be  somewhat  intuitive.  Indeed,  the  desire  and  ability  to  pool 
resources  is  certainly  not  just  an  M&S  community  issue;  Figure  4  identifies  the  Levels  of  Information 
Systems  Interoperability  (LISI)[m]  and  the  NATO  C3  Technical  Architecture  Reference  Model  for 
Interoperability,  both  of  which  categorise  generic  information  sharing  and  data  exchange  in  a  progressive 
and  hierarchical  fashion.  Even  though  the  general  concept  of  interoperability  may  have  global 
commonality,  the  precise  understanding  and  associated  benefits  within  specific  domains  will  vary. 


LISI  -  Levels  of  Information  System 

NMI-NC3TA  (NATO  C3  Technical  Architecture) 

Interoperability 

Reference  Model  for  Interoperability 

Isolated  Systems 

No  Data  Exchange 

No  physical  connections 

No  physical  connection 

Connected  Systems 

Unstructured  Data  Exchange 

Homogeneous  product  exchange 

Human  readable  free  text 

Distributed  Systems 

Structured  Data  Exchange 

Heterogeneous  product  exchange 

Human  interpretable, 

Integrated  Systems 

Manual  action  required 

Shared  apps  &  shared  data 

Seamless  Data  Sharing 

Universal  Systems 

Common  data  model 

Enterprise-wide  shared  systems 

Automated  data  sharing 

Seamless  Information  Sharing 

Universal  interpretation 

Cooperative  data  processing 

Figure  4:  Levels  of  Interoperability. 


Within  the  defence  M&S  realm,  interoperability  has  specific  benefits  and  challenges  from  technical  and 
non-technical  perspectives.  First  and  foremost,  the  ability  to  interoperate  disparate  simulation  systems 
promotes  the  train  as  you  fight  philosophy  and  enables  the  expansion  of  individual  activities  to  team 
activities.  The  networking  of  live,  virtual  and  constructive  simulation  systems  amongst  themselves  and  to 
real  world  systems  has  facilitated  both  the  move  away  from  training,  analysis  and  experimentation  in 
isolation,  and  the  creation  of  collaborative  working  environments.  It  is  within  these  synthetic 
environments2  that  defence  organisations  have  found  some  relief  from  the  fiscal  constraints  imposed  over 
the  past  15  to  20  years.  New  and  innovative  methods,  enabled  by  advances  in  technology,  are  beginning  to 
create  alternative  means  to  carry  out  defence  activities  where  the  lack  of  resources  simply  will  not  allow 
one  to  employ  the  live  systems  as  in  the  past.  Despite  the  bright  future  that  M&S  seems  to  promise,  these 
potential  benefits  do  not  come  without  their  issues  and  challenges.  Some  of  these  challenges  will  be 
highlighted  later  in  the  paper.  Finally,  a  topic  that  will  be  examined  in  more  detail  in  the  next  section, 


2 

The  UK  MoD  defines  a  synthetic  environment  as  "A  computer-based  representation  of  the  real  world,  usually  a  current  or 
future  battle  space,  within  which  any  combination  of  'players'  may  interact.  The  'players'  may  be  computer  models, 
simulations,  people  or  instrumented  real  equipments."  www.mod.uk/issues/simulation/policy.htm 
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simulation  interoperability  has  lead  to  the  concept  of  reusing  any  existing  M&S  investment  in  new  or 
different  ways. 


INTEROPERABILITY  AND  REUSE 

Reuse  (the  concept  of  taking  something  that  has  already  been  designed  and  developed  for  one  purpose  and 
using  it  for  a  similar  or  another  purpose)  is  a  topic  that  is  not  new  to  the  science  and  engineering  realms2 3. 
Indeed  the  automotive  industry  has  leveraged  this  concept  for  many  decades.  In  the  software  realm, 
designers,  developers  and  coders  have  been  striving  to  produce  modular  systems  with  the  intent  of  being 
able  to  reuse  component  elements  (such  as  functions)  from  one  application  to  the  next.  In  fact,  “code  reuse 
is  increasing  with  the  advent  of  standards  such  as  COM  and  JavaBeans.”[lv]  Thus,  it  is  not  surprising  that 
reuse  has  become  a  prominent  theme  in  M&S. 

A  key  issue  when  considering  reuse  is  what  exactly  a  simulation  practitioner  should  aim  to  reuse.  Many 
defence  M&S  agencies  have  established  structured  and  managed  collections  of  models  and  simulations, 
known,  in  most  instances,  as  modelling  and  simulation  resource  repositories  (MSRR)4.  Typically,  these 
repositories  list  simulation  applications  representing  completed  executable  systems  as  opposed  to  reusable 
component  models.  This  level  of  reuse  may  or  may  not  be  appropriate;  what  should  M&S  practitioners 
aim  to  reuse:  whole  models;  sub-models;  components;  data;  databases?  Figure  5  uses  a  conceptual  model 
of  an  aircraft  in  an  attempt  to  depict  the  various  levels  at  which  model  reuse  might  be  appropriate.  In  fact, 
not  all  communities  agree  that  reuse  is  always  appropriate.  Take  for  instance  the  operations  research  (OR) 
community,  which  has  been  developing  and  employing  models  for  many  decades.  This  community  tends 
to  abide  by  the  fundamental  definition  of  a  model  -  a  representation  of  an  element  of  the  real  world  for  a 
specific  purpose.  As  such,  the  OR  view  is  that  any  useful  model  will  be  fit  for  purpose  and  should  not  be 
used  for  applications  other  than  that  for  which  it  was  designed.  Another  perspective  is  that  one  cannot 
simply  keep  complex  components  on  the  shelf  waiting  to  be  reused;  this  would  likely  result  in  a 
deterioration  of  the  knowledge  and  skill  associated  with  models.  Whether  or  not  there  is  a  conclusive 
answer  to  this  question  is  a  debatable  issue. 
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Figure  5:  Conceptual  Model  Example. 


2 

An  example  that  makes  significant  use  of  this  concept  is  the  recent  upgrade  to  the  US  Marine  Corps  AH-1  and  UH-1 
helicopter  fleets  wherein  an  84%  commonality  of  components  (drive  train,  cockpit,  software)  between  the  two  platforms  will 
ensure  a  reduction  in  logistic  support  and  strategic  lift  requirements.  (USMC  Concepts  +  Programs,  Aviation  Combat  Element 
legacy  Platform  Modernization,  March  2005) 

4  Examples  include:  the  USAF  -  afmsrr.afams.af.mil;  the  US  Army  -  www.msrr.army.mil;  the  Canadian  Forces  -  www.drdc- 
rddc .  gc .  ca/  seco/  msrre .  htm. 
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Assuming  that  reuse  is  appropriate  and  viable  in  the  M&S  community,  one  can  begin  to  see  that 
interoperability  and  reuse  are  closely  related.  In  order  to  reuse  a  given  component  within  a  larger  system, 
one  must  ensure  that  it  can  interoperate  with  the  other  elements  of  the  systems  (at  least  those  with  which 
data/information  must  be  exchanged).  This  issue  is  one  of  the  many  at  the  forefront  of  research  efforts  in 
the  M&S  realm.  Over  the  past  two  decades  networked  and  distributed  simulation  activities  have  expended 
significant  effort  on  achieving  interoperability  amongst  disparate  systems.  Figure  6  portrays  a  ladder  of 
interoperability  and  reuse  signifying  progress  as  networked  and  distributed  simulation  technologies  and 
methodologies  have  matured[v].  This  push  up  the  ladder  of  interoperability  has  been  facilitated  by  an 
increase  in  reuse  through  a  broadening  in  technical  concepts  and  standards. 


The  increase  in  reuse  and  the  broadening  in  interoperability  have  impacted  defence  processes,  technology, 
operations  and  culture.  Considering  M&S  as  a  tool  that  has  potential  to  be  applied  across  the  entire 
spectrum  of  defence  activity,  increased  interoperability  and  reuse  facilitate  the  dissolution  of  stove-piped 
capability  generation.  One  current  example  of  pan-defence  application  of  M&S  is  found  in  the  Joint  Strike 
Fighter  (JSF)  Distributed  Product  Description  (DPD)5  that  operates  in  two  collaborative  environments: 
one  managed  by  the  government  (focused  on  strike  warfare)  and  another  managed  by  the  contractor 
(focused  on  engineering  and  manufacturing)^.  Figure  7,  from  the  JSF  DPD  Project  Coordinator,  provides 
an  overview  of  how  M&S  serves  as  a  facilitation  layer  between  the  JSF  DPD  and  the  various  functional 
elements  in  the  life  cycle.  The  push  towards  distributed  and  federated  systems,  and  the  rapid  advances  in 
information  technology,  has  prompted  defence  organisations  to  support,  adopt  and  leverage  commercial 
standards.  Distributed  Interactive  Simulation  (DIS)  and  the  High  Level  Architecture  (HLA)  began  as  US 
DoD  efforts  and  then  transitioned  to  IEEE  standards  (IEEE  1278  and  IEEE  1516  respectively). 


5  A  DPD  is  a  web-based,  distributed  collection  of  authoritative  information  provided  to  users  in  such  a  manner  as  to  appear  as  a 
single  product  representation. 
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Figure  7  :  JSF  DPD  (www.dtic.mil/ndia). 


One  final  example  demonstrates  the  impact  on  operations  and  culture  -  the  push  towards  implementing  the 
concept  of  network  enabled  capability  (NEC).6  In  simple  terms,  NEC  aims  to  leverage  technical 
interoperability  to  eventually  achieve  conceptual  interoperability  amongst  distributed,  disparate  forces  to 
generate  common,  more  thorough  situational  awareness.  Herein  lies  the  parallel:  networked  simulations 
aim  to  achieve  a  similar  goal  by  bringing  together  distributed  resources  for  a  whole  that  is  greater  than  the 
sum  of  its  parts. 


CHALLENGES 

It  should  be  evident  by  this  point  that  interoperability  and  integration  as  related  to  M&S  is  a  non-trivial 
task.  There  are  challenges  both  within  the  realm  of  M&S  itself  and  between  the  M&S  realm  and  the  real 
world. 

Technology  has  made  significant  advances,  to  the  point  where  technical  and  syntactic  interoperability 
have  been  made  easier  (but  certainly  not  trivial).  Greater  challenges  reside  in  higher  levels  of 
interoperability  (i.e.  the  appropriate  alignment  of  purposes  between  distributed  simulation  participants); 
this  becomes  more  important  and  challenging  when  one  looks  to  span  M&S  across  the  entire  life  cycle  of 
a  capability.  Other  challenges  include: 

•  Matching  capability  amongst  participating  simulations; 

•  Matching  fidelity  amongst  participating  systems; 

•  Sharing  information  between  services  and  across  borders  (functional,  domain  and  political);  and 

•  Integrating  legacy  systems  that  still  have  a  purpose. 

When  examining  challenges  that  exist  between  the  M&S  realm  and  real  world  one  must  first  recall  the 
fundamental  definition  of  a  model:  a  representation  of  an  element  of  the  real  world  for  a  purpose. 
As  such,  models,  by  nature,  will  have  gaps  when  compared  to  the  real  world.  As  one  attempts  to 


6  For  a  more  detailed  look  at  NEC  from  a  UK  MoD  perspective  see  www.mod.uk/issues/nec/ . 
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interoperate  M&S  systems  with  real  world  systems,  these  gaps  could  prove  to  be  problematic;  the  real 
world  system  might  attempt  to  exchange,  or  might  be  expecting  data/information  for  which  the  simulation 
was  not  designed  to  handle.  As  an  extension  to  this  concept,  in  specifying  new  simulation  systems, 
designers  might  encounter  a  desire  to  incorporate  too  much  complexity  (in  an  effort  to  allow  a  more 
seamless  interface  with  the  real  world);  consequently,  a  challenge  to  abstract  appropriately  arises. 
Fundamentally,  one  must  ensure  that  the  necessary  data  can  be  exchanged  between  the  two  realms  and  that 
any  exceptions  are  handled  gracefully. 


SUMMARY 

Interoperability  has  long  been  the  Holy  Grail  within  defence  communities  world  wide  -  particularly  of  late 
with  the  increase  in  joint  and  coalition  operations.  The  shift  to  an  increased  use  of  M&S  for  training  and 
mission  rehearsal  has  seen  a  transfer  of  similar  issues  across  to  the  M&S  realm.  Interoperability  of 
distributed  simulation  systems  began  wider  use  in  the  early  1980’s  and  has  seen  steady  increase  ever  since. 
The  concept  of  reuse  has  also  become  more  prominent  as  it  is  closely  related  to,  and  can  facilitate, 
interoperability  -  the  primary  question  here  is  at  what  level  does  one  focus  reuse  efforts. 

Benefits  do  not  come  without  their  challenges.  Many  technological  issues  have  been  addressed  over  the 
past  two  decades  with  a  certain  degree  of  success.  One  must  also  address  non-technical  challenges  -  those 
challenges  that  have  their  roots  in  practical  and  conceptual  level  views  of  the  problem  domain.  Finally, 
as  the  overlap  between  the  M&S  realm  and  the  real  world  grows,  more  challenges  will  surface. 
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Why  Network  Simulations  - 1 


Traditional  Reasons : 

□  To  enable  multi-user  access  or  involvement 

□  For  delivery  to  remote  sites  &  for  access  to  scarce  /  central 
resources 

□  To  drive  ('stimulate’)  other  resources  from  simulation 

□  To  build  single  systems  from  multiple  components 


□  Given  the  growth  of  networking  and  the  internet  generally 
Why  shouldn’t  there  also  be  similar  /  parallel  benefits  from 
networking  of  M&S  systems? 
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Some  Example  Networked.  Simulations 


□  US  Janus  wargame 


□  UK  ABACUS  wargame 


□  Platform  Simulators 


□  High  Level  CAST  (US  JTC,  UK  JOCASTS) 


□  Commercial  games  (Doom,  Quake,  HL,  etc.) 


All  are  simulations  -  but  they  employ  different  network  architectures. 
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Classical  Simulation  Architectures 


□  Terminal-Server: 

-  Central  server  computer  driving  ‘dumb’  input/output  stations 

-  Battle  assessed/executed  centrally 

-  Outstations  do  no  significant  processing  &  retain  no  data 

□  Client-Server: 

-  Still  central  server  computer  executing  battle 

-  Outstations  now  do  some  significant  processing 

-  Outstations  do  retain/store  data. 


Closed  and  Proprietary 
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Classical  Simulation  Architectures 


□  JANUS  Wargame  Layout 

-  Multiple  player  stations  (up  to  16) 

-  Single  host  computer 


Terminal  Server 


-  Central  server  runs  battle,  does  all  processing  and  holds  ALL 
data 

-  Player  stations  need  only  be  'dumb’  terminals  (&  hold  NO  data) 

-  Server  literally  sends  out  'graphics’  commands  (ie  no  explicit 
battle  information  or  data  passes  across  network) 

-  Graphics  commands  interpreted  by  a  special  program  (RTX) 

-  RTX  may  run  on  actual  player  station  or  elsewhere  on  nework 

-  Player  station  simply  responds  to  graphics  commands 


-  Centralised  Mainframe  or  'Terminal-server’  architecture. 


Classical  Simulation  Architectures 


Controller 

-  All  assessments  made  on  central  server 

-  Server  sends  battle  update  information  over  network 

-  Player  stations  run  an  intelligent  process  (&  retain  ‘some’  data) 

-  Displaying  locally  stored  map  data 

-  Selectively  displaying  combat  information 

-  Still  a  disparity  between  degrees  of  processing  at  Clients  and  Server. 

-  Client-Server  architecture 

-  Extent  of  client  processing  may  vary  (‘Fat’  &  ‘Thin’  clients)  _ 

1)1 
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Interoperability  Basics 

□  What  is  Interoperability? 

-  “The  ability  of  Alliance  forces  and,  when  appropriate,  forces  of 
Partner  and  other  nations  to  train,  exercise  and  operate 
effectively  together  in  the  execution  of  assigned  missions  and 

tasks.  ”  APP-6  (V)  NATO  Glossary  of  Terms  and  Definitions,  August  2000 

-  inter-  “among  ...  carried  on  between” 

-  operate  -  “to  carry  on  a  military ...  action  or  mission” 

Longman  Dictionary  of  the  English  Language,  1984 


□  Why  strive  for  Interoperability? 

-  Effectiveness  -  the  “Train  as  you  fight ”  philosophy 

-  Efficiency  -  expand  individual  training  to  team  training 


“The  whole  is  better  than  the  sum  of  the  parts” 
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Information  Systems  Interoperability 

Interoperability  is  not  just  a  Modelling  &  Simulation  community  issue.... 


□  LISI  -  Levels  of  Information  System 

Interoperability 

□  Isolated  Systems 

-  No  physical  connections 

□  Connected  Systems 

-  Homogeneous  product  exchange 

□  Distributed  Systems 

-  Heterogeneous  product  exchange 

□  Integrated  Systems 

-  Shared  apps  &  shared  data 

□  Universal  Systems 

-  Enterprise-wide  shared  systems 


□  NMI  -  NC3TA  (NATO  C3  Technical 

Architecture)  Reference  Model  for 

Interoperability 

□  No  Data  Exchange 

-  No  physical  connection 

□  Unstructured  Data  Exchange 

-  Human  readable  free  text 

□  Structured  Data  Exchange 

-  Human  interpretable, 

-  Manual  action  required 

□  Seamless  Data  Sharing 

-  Common  data  model 

-  Automated  data  sharing 

□  Seamless  Information  Sharing 

-  Universal  interpretation 

-  Cooperative  data  processing 


Tift 

mm 

¥ 


Data  consistency,  commonality,  unambiguous  interpretation. 
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ComjzutincL  Analogy 

□  PC  S/W  and  H/W  development  analogy 
-  From  “bespoke”  to  plug  and  play 

□  From  early  machines  where  care  had  to  be  taken  in  selecting  and 
integrating  components  and  peripherals  to  ensure  they  would 
operate  together  and  where  software  often  had  to  be  written 
specifically  with  knowledge  of  the  hardware  upon  which  it  was 
hosted  and  the  peripherals  with  which  it  might  be  used. 

□  To  current  day  machines  and  operating  systems  where  users 
expect  that  most  components  and  peripherals  will  work  across 
brands  and  vendors  (ie.  “plug  and  play”)  to  allow  the  freedom  to 
customise  and  adapt  any  particular  system  as  required.  Such 
cross  platform  functionality  depends  on  standard  interfaces 
implemented  in  hardware,  device  drivers,  operating  system  etc. 
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Interoperability  Basics 

□  Why  Interoperability  in  M&S? 

-  Same  general  reasons  ...  plus  ... 

-  Generate  the  ability  to  link  various  types  and  categories  of 
simulations  and  simulators  together 


-  Generate  the  ability  to  link  simulations  to  real  world  equipment 
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Why  Network  Simulations  -  2 


Emerging  New  Application  reasons : 

□  For  interaction  between  remote  sites  (eg  coalition  ops). 

□  To  add  capability  or  functionality  to  existing  M&S  applications. 

□  To  communicate  and  cooperate  with  different  organisations,  agencies, 
services,  companies,  countries... 

□  To  share  processing  loads  across  systems  (distributed  computing). 

□  To  re-use  existing  M&S  investment  in  new  ways,  contributing  to  improved 
efficiency  and  effectiveness 


Federations  of  networked  federates  (M&S  components) 


Interoperability  and  Reuse 

□  Not  surprising,  in  terms  of  finance,  resources  &  consistency,  that 
reuse  should  be  a  prominent  theme  in  M&S.  But  reuse  of: 

-  Whole  models  and/or  model  components  (sub-models)  ? 

-  Data  and  Databases? 

-  etc 


□  However: 

-  Not  all  communities  agree  that  re-use  is  always  appropriate 

-  Also,  how  easy  is  it  to  make  a  legacy  simulation  or  component 
interoperable  with  a  newer,  current  day  implementation? 

□  This  is  where  we  begin  to  expose  the  concept  of  varying  levels  of 
interoperability  (to  be  expanded  upon  later) 


□  Notwithstanding,  reuse  has  matured  over  time  and  has  brought 
with  it,  in  parallel,  a  progression  up  the  ladder  of  interoperability 
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Interoperability  and  Reuse 


BOMs 


HLA 
(c.  1995) 


DIS 

(c.  1993) 


SIMNET 
(c.  1983) 
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Through  Life  Implications 

□  Models  and  simulations  that  are  designed  and  developed  during 
pre-acquisition  have  the  potential  to  be  reused  or  modified  for  use 
throughout  the  remainder  of  a  system’s  life  cycle. 


Pre-  Acquisition 


In- 

Service 


Life  Cycle 
Manage  &  Support 


Training 

Rehearsal 


Disposal 


SeBA 


Taken  from  Espenant,  JSMARTS  Workshop,  June  2004,  Canada 
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Through  Life  Implications 

□  A  good  example  is  the  JSF  project  and  its  associated  Virtual  Strike 
Warfare  Environment  (VSWE)  and  Distributed  Product  Description  (DPD) 
concept  (SISO  Fall  2000  SIW  presentation  by  Hollenbach) 


JSF  DPD  -  The  Hub  of  IPPD  Process 


Concept  Development 


System 

Requirements 


——ii - 1  Functional  Design 


c=- 

JORD 

JNIS 

Cost,  Schedule  & 
Program  Mgmt 


Physical  &  Info 
System  Design 


Manufacturing 


Mission  Planning, 
Wargaming 


Logistics 


Training 


2000  Fall  Simulation 

3  Interoperability  Workshop 
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Distributed  /  Federated  Systems 

□  Distributed  System  (Tanenbaum,  2002) 

“A  distributed  system  is  a  collection  of  independent  computers 
that  appears  to  its  users  as  a  single  coherent  system.” 

□  Federation  -  “an  organization  formed  by  merging  several  groups” 

www.wordreference.com 

□  Federated  System 

-  Each  element  manages  itself  internally  while  contributing  to  the 
whole,  but  does  not  communicate  independently  outside  of  the 
federation 
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Parallels  With  NEC/NCO 


□  Network  Enabled  Capability  /  Network  Centric  Operations 

-  Key  Concepts: 

-  Distributed  /  Knowledgeable  /  Linked 

-  NEC  Chain: 

-  Robust  network  improves  information  sharing 

-  Information  sharing  enhances  quality  &  shared  SA 

-  Shared  SA  enables  collaboration  and  self  synchronization 

-  Result  is  increased  mission  effectiveness 


□  Evolution  in  thinking: 

-  Platform  Centric  — ►  Integrated  Systems  — ►  Network  Centric 

-  NEC  is  about  more  than  just  the  technology 

-  Human  and  organizational  behaviour  (  Conceptual 

-  Focus  on  information  flow  and  interaction 

Alberts,  Network  Centric  Warfare  DoD  CCRP 
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Parallels  With  NEC/NCO 


□  Proponents  of  NEC/NCO  (particularly  in  the  USA)  are  working  toward 
establishing  the  Global  Information  Grid  (GIG) 

□  The  GIG  will  function  on  a  “POST  AND  SMART  PULL  ”  concept 

-  Information  is  posted  to  grid  by  generators 

-  Potential  users  seek  and  pull  what  they  need 

Alberts,  Power  to  the  Edge ,  DoD  CCRP 

□  One  concept  is  that  simulation  systems  will  have  portals  to  GIG 

-  To  allow  stimulation  of  real  world  systems 

-  To  collect  data  for  simulation  testing,  V&V,  etc 


□  Interoperability  becomes  critical  across  yet  another  boundary 
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Challenges 

□  Within  the  realm  of  simulation  on  its  own: 

-  Aligning  purposes 

-  Matching  capabilities 

-  Matching  fidelity 

-  Sharing  information 

-  Integrating  legacy  systems 


□  Between  M&S  realm  and  “real  world”: 

-  Models  are  representations  and  inherently  have  gaps  when 
compared  to  the  real  world 

-  Interoperability  with  real  world  systems  adds  more  complexity 

-  Must  ensure  required  data  can  be  exchanged  and  any 
exceptions  are  handled  gracefully 
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Summary 


□  Interoperability,  although  simple  in  concept,  is  vast  in  practice,  and 
the  associated  effort  can  vary  depending  on  the  work  at  hand  and 
the  scope  of  the  activity 

-  Highly  specialized,  focused  activity 

-  System  through-life  application  spanning  years 

□  Regardless,  interoperability  is  a  factor  in  today’s  complex 
simulation  environments 

□  Furthermore,  interoperability  is  becoming  more  important  as 
simulation  systems  are  interconnected  with  real  world  systems 


□  Higher  levels  of  efficiency  and  effectiveness  are  possible  in 
achieving  interoperability  -  it  must  be  addressed  early  on 


Questions  /  Discussion 
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